The invention concerns a customisation or initialisation method and device for portable communicating devices such as smart cards.
With the coming of open or closed programmable smart cards, it is possible to have said smart cards execute service applications, that is to say executable software programs, coming from various sources. To that end, a programmable card comprises rewritable memory areas for storing one or more applications according to its use, and a processor able to execute such applications.
These service applications, also known by the term “applets”, come in the form of complex programs, generally designed by means of high-level languages such as JavaCard, C++, Visual Basic, etc. Each service application comprises an “applications” part which provides the execution of the program in normal mode, and an “administrative” part which is used only at an initial stage for customising the application to the holder of the card. The stored data which constitute the software means of this administrative part are designated “administrative code”, or “customisation code”. This code can occupy up to several tenths of the whole of the code forming the application. Within the context of the invention, the term “customisation” also comprises any other similar process to be executed in an application, such as parameter initialisation.
The customisation code is used in particular for the loading into the card of data specific to the user, so that they can be read and used if necessary during normal execution of the application. Conventionally, the on-board customisation code in a smart card or other portable communicating device must provide the following functions:                dialogue according to an established protocol with a customisation program outside the card—a distinction is then made of the on-card customisation code, contained in the rewritable memory area, and the off-card customisation code, contained for example in a remote terminal or a server;        recognition of instructions for identifying and loading fields of data intended to contain values specific to the customisation; and        loading of these customisation values into corresponding registers in the memory area of the card.        
FIG. 1 illustrates in a simplified manner a few steps in the conventional process for loading customisation data from the outside into respective storage fields of a programmable card, during customisation of an application of this card. In the example, the card is connected by a terminal to a server or remote terminal which fills in the fields by means of an off-card customisation code.
For each field in the card to be filled in, the off-card customisation code comprises a first instruction, intended for the on-card customisation program, which indicates the designated specific field. The on-card customisation code must recognise each of these instructions in order to select the designated field and act accordingly. This recognition necessitates a decoding instruction specific to each field, which must be stored with the on-card customisation code.
Next, the off-card customisation code transmits the personal data to be written into the previously designated field. Upon reception of these data, the on-card customisation code executes the instructions necessary for loading them into a designated register according to the preceding instruction.
Once the first field has been loaded in this way, the process is repeated in an identical manner for each of the other fields. Thus, in the example of FIG. 1, n personal information elements are loaded into respective fields of the card, each being preceded by a specific instruction which must be identified by the on-card customisation code.
By way of example, the process for customising an application intended for a medical services tracking card may fill in the following fields: field 1=surname, field 2=forename, field 3=social security number, field 4=height, field 5=weight, etc. Similarly, the process for customising another application, for example intended for a bank card, will fill in the following fields: field 1=personal identification number (PIN), field 2=maximum number of code input attempts, field 3=authorised weekly debit limit, field 4=bank code, field 5=branch code, etc.
The instructions relating to each field must not only identify it, but also indicate the form of the data contained (number and type of characters, formatting, etc.).
As these information elements are specific to each application, it follows that each application stored in a card must have its specific customisation code. The space occupied by this on-card customisation code increases with the number of applications loaded, and can occupy in total several tenths of the memory area of the card dedicated to the applications.
To sum up, this conventional method suffers from the following drawbacks:                it adapts with difficulty to remote customisations, since the method generally requires an exchange of a large number of commands, which can be very difficult to provide on a slow network; and        
the customisation commands must be coded in all the applications of the card, which occupies a large memory area in the card.